Modern computing systems execute a variety of requests concurrently and operate in a dynamic environment of cooperative systems, each comprising of numerous hardware components subject to failure or degradation.
The need to regulate concurrent hardware and software “events” has led to the development of a field which may be generically termed “Workload Management.” For the purposes of this application, “events” comprise, but are not limited to, one or more signals, semaphores, periods of time, hardware, software, business requirements, etc.
Workload management techniques focus on managing or regulating a multitude of individual yet concurrent requests in a computing system by effectively controlling resource usage within the computing system. Resources may include any component of the computing system, such as CPU (central processing unit) usage, hard disk or other storage means usage, or I/O (input/output) usage.
Workload management techniques fall short of implementing a full system regulation, as they do not manage unforeseen impacts, such as unplanned situations (e.g., a request volume surge, the exhaustion of shared resources, or external conditions like component outages) or even planned situations (e.g., systems maintenance or data load).
Many different types of system conditions or events can impact negatively the performance of requests currently executing on a computer system. These events can remain undetected for a prolonged period of time, causing a compounding negative effect on requests executing during that interval. When problematic events are detected, sometimes in an ad hoc and manual fashion, the computing system administrator may still not be able to take an appropriate course of action, and may either delay corrective action, act incorrectly or not act at all.
A typical impact of not managing for system conditions is to deliver inconsistent response times to users. For example, often systems execute in an environment of very cyclical usage over the course of any day, week, or other business cycle. If a user ran a report near standalone on a Wednesday afternoon, she may expect that same performance with many concurrent users on a Monday morning. However, based on the laws of linear systems performance, a request simply cannot deliver the same response time when running stand-alone as when it runs competing with high volumes of concurrency.
Therefore, while rule-based workload management can be effective in a controlled environment without external impacts, it fails to respond effectively when those external impacts are present.
Further, as database management systems continue to increase in function and expand into new application areas, the diversity of database workloads is increasing as well. In addition to the classic relational database management system (DBMS) workload consisting of short transactions running concurrently with long decision support queries, one can expect to see workloads comprising an even wider range of system demands in the future. New complex data types (e.g. large objects—image, audio, video, etc.) and new active data warehouse requirements consisting of capacity on demand, data replication, fault-tolerance, dual active query processing, recursion, user defined type's, external user defined functions, etc. will result in widely varying memory, processor, disk and network demands on database systems, including multiple systems (Multi-systems) running in parallel.
This new set of diverse requirements proposes a different mechanism for managing workloads on database systems. The problem of managing and adjusting DBMS resources (tasks, memory, disk, etc.) across multiple systems in order to achieve a set of response time goals for workloads is the inter-dependence between systems that compete for shared resources.
Ideally, a DBMS should be able to accept performance goals for a workload and dynamically adjust its own performance “knobs” using the goals as a guide. Given performance objectives for each workload, the problem is further complicated by the fact that workloads can interfere with each other's performance through competition for shared resources. Because of this interference, the DBMS may find a “knob” setting that achieves the goal for one workload but at the same time makes it impossible to achieve the goal for some other workloads.
The performance goals for each workload will vary widely as well, and may or may not be related to their resource demands. For example, two workloads that execute the exact same application and DBMS code could have differing performance goals simply because they were submitted on different machines, i.e., different or cross-organizations. Conversely, even though two workloads have similar performance objectives, they may have very different resource demands. This problem becomes compounded when trying to manage workloads across multiple systems.
A complete solution to the problem of satisfying all workload performance goals across multi-systems must employ more than one mechanism; each class can have different resource consumption patterns, so the most effective “knob” (or performance setting) for controlling performance may be different for each workload. Controlling the performance for such a workload by “manually” adjusting DBMS performance “knobs” will become increasingly impractical. Even if the DBMS can determine which “knobs” to adjust, it must still decide in which dimension and how far each one should be turned. In other words, the DBMS must translate a performance goal specification into a particular resource allocation that will achieve that goal. How it should perform this translation is a complex problem to solve.
In summary, there are very few examples of goal-oriented workload management algorithms that exist in the prior art for multi-systems. More over, the few existing examples all primarily control a single “knob”.
Accordingly, what is needed is the capability to manage workloads in a multi-system environment.